Device drivers are critical components of an operating system (OS), as they are the software that controls peripheral hardware, such as disks, network interfaces or graphics displays. They make up a large fraction of OS code, for example around 70% in Linux.
Drivers are the leading reliability hazard in modern OSs. Drivers are known to be responsible for the majority of OS failures, and have been shown to have three to seven times the defect density of other OS code. The leading class of driver defects, comprising about 40% of all driver bugs, are related to incorrect handling of the hardware-software interface. These device hardware-software interface bugs include incorrect use of device registers, sending commands to the device in the wrong order, or incorrectly interpreting device responses.
Hardware developers define the software interface of the device and map it down to the low-level hardware design. This design is thoroughly tested by the hardware verification team to make sure that it correctly implements the required interface before transferring it to silicon. The focus in this process is on ensuring hardware correctness. Driver support is a secondary concern to hardware engineers.
Since mistakes are expensive and time consuming to fix once the design has been synthesised in silicon, much effort is put into initially testing/verifying the design in a simulated environment called a ‘testbench’ prior to producing hardware.
There exists several approaches to structuring the device testbench. The majority of modern testbenches follow the layered structure shown in FIG. 1(a) which models the hardware and software structure of a real computer. The testbench is built around the register transfer level (RTL) model of the device, also known as the design under test (DUT) 30. This is the RTL design being verified. The DUT 30 is connected to a functional model (BFM) 32 that simulates the I/O bus the device is connected to. It accepts bus read and write commands from higher layers and translates them into bus transactions at the device interface.
The agent module 34 consists of functions and associated state that implement high-level device transactions such as sending network packets, changing device configuration, interrupt handling, etc.
The scenario layer 36 consists of test scenarios designed to thoroughly test the device in various modes. These scenarios can be directed or randomised. A directed scenario consists of a fixed sequence of commands, whereas a randomised scenario generates random command sequences subject to a set of constraints.
Finally, the bottom layer 38 of the testbench simulates the physical medium that the device controls. For instance, if the DUT is an Ethernet MAC controller, this layer simulates an Ethernet PHY chip. In addition to the above components, a complete testbench contains other modules (not shown), including monitors, scoreboards, and coverage points that check whether the device behaves correctly during tests and whether the tests have covered the entire device functionality.
FIG. 1(b) shows the OS architecture of the operating system's I/O stack. The hardware device 42 is a hardware device that enables a computer system to communicate with the outside world. Examples of I/O devices 42 include human-interface devices, e.g., keyboards and mice, which enable communication with a human operator, networking devices, e.g., Ethernet controllers, which enable communication between different computer systems, and storage devices, e.g., hard disk drives or CDROM drives, which allow the computer system to store data on non-volatile media.
The hardware device 42 is connected to the physical medium 44 and an I/O bus that is a hardware subsystem that transfers data between the central processing unit (CPU) of a computer system and I/O devices 42.
The I/O bus transport is part of the OS that enables device drivers 46 to communicate with the devices connected to the I/O bus.
A device driver 46 is a component of the OS that is responsible for controlling an I/O device 42. It provides services to the rest of the OS 50 and relies on services provided by the bus transport layer 60.
In order to enable the software driver team to produce a driver for the device, hardware designers provide a document, known as the device datasheet, that describes device registers and behaviour from the software perspective. Since driver developers usually do not have access to hardware design internals nor the expertise required to analyse them, they are bound to rely on the datasheet and personal communication with the hardware team in their work. In practice, datasheets are often incomplete and inaccurate, which results in numerous driver defects.
Another problem that driver developers face is the complexity of testing the driver. While the driver can issue arbitrary commands to the device, it only has partial control over its physical environment, including the I/O bus and the external medium that the device is connected to. This makes thorough testing difficult to achieve. For instance, testing how the driver handles internal device FIFO overflow due to bus contention or packet transmission failure due to multiple network collisions is difficult in practice. As a result, most drivers are only well tested in common scenarios and do not adequately handle various corner cases.
Any discussion of documents, acts, materials, devices, articles or the like which has been included in the present specification is solely for the purpose of providing a context for the present disclosure. It is not to be taken as an admission that any or all of these matters form part of the prior art base or were common general knowledge in the field relevant to the present disclosure as it existed before the priority date of each claim of this application.
Throughout this specification the word “comprise”, or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated element, integer or step, or group of elements, integers or steps, but not the exclusion of any other element, integer or step, or group of elements, integers or steps.